﻿<p>The decomposition relationship,
<em>IfcRelDecomposes</em>, defines the general concept of elements
being composed or decomposed. The decomposition relationship
denotes a whole/part hierarchy with the ability to navigate from
the whole (the composition) to the parts and vice versa.</p>
<p>Decompositions may be constrained by requiring both, the whole
and its parts, to be of the same type - thus establishing a
nesting relationship. Or they may require some form of physical
containment, thus establishing special types of aggregation
relationships.</p>

<blockquote class="note">
NOTE&nbsp; There are two special names for
decomposition, which are linguistically distinguished, nesting
and aggregation. The subtypes of <em>IfcRelDecomposes</em> will
introduce either the nesting or aggregation convention (see
<em>IfcRelNests</em> and <em>IfcRelAggregates</em>).
</blockquote>

<blockquote class="example">
EXAMPLE&nbsp; A cost element is a nest of other cost
elements. Or a structural frame is an aggregation of beams and
columns. Both are applications of decomposition
relationship.
</blockquote>
<p>Decompositions imply a dependency, i.e. the definition of the
whole depends on the definition of the parts and the parts depend
on the existence of the whole. The decomposition relationship can
be applied in a recursive manner, i.e. a decomposed element can
be part in another decomposition. Cyclic references have to be
prevented at application level.</p>

<blockquote class="history">
HISTORY&nbsp; New entity in IFC1.5, it is a generalisation of the IFC2.0 entity <em>IfcRelNests</em>.
</blockquote>

<blockquote class="change-ifc2x4">
IFC4 CHANGE&nbsp; The differentiation between the aggregation and nesting is determined to be a non-ordered or an ordered collection of parts. The attributes <em>RelatingObject</em> and <em>RelatedObjects</em> have been demoted to the subtypes.
</blockquote>